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Technical Field 

The present invention relates generally to the display of messages from multiple 
electronic devices by a network connected display device, and more particularly, to a 
display device executing a priority messaging protocol. 

Background of the Invention 

Display devices connected to a network are often used to display data to a user 
that originates from other devices attached to the network. This process works 
satisfactorily when the display device is dedicated to a single Application/Device. 
However, problems occur when more than one network device at a time attempts to use 
the display device. 

There are currently two main approaches for allowing multiple network devices 
to share a single display device. In the first approach, the display device partitions its 
display surface upon which the messages are displayed to the user into separate discrete 
areas. Each discrete area becomes dedicated to a single device/application. Any 
network device sending a message to the display device has its display message 
redirected to the portion of the display surface assigned to that network device. The 
result of such an approach, is that each display device has less available display surface 
dedicated to each device. Accordingly, the size of the message being displayed is 
reduced, sometimes greatly reduced. Another approach allows information to be 
displayed from a device when received, thereby overwriting information displayed for 
another device on the display surface. This approach automatically displays an 
incoming message upon its receipt with no prioritization factored into the display 
process. The problem caused by this approach is that important messages may get 
overwritten by less important messages. For example, in an automobile, a display 
device might display a warning about low fuel levels on its display surface and have the 
message overwritten by a warning about low windshield washer fluid levels. Since the 
messages aren't prioritized as they arrive, the resultant display of messages occurs in an 
inconsistent and haphazard fashion. 
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to the problem of multiple networked devices sharing a single display device. Either the 
messages are inconsistently displayed, or the displayed messages quickly get too small 
to easily read. 

Summary of the Invention 

The present invention addresses the display limitations encountered by display 
devices attempting to display messages received from multiple network devices. It 
enables a display device to efficiently allocate its display surface while receiving 
messages from multiple network devices. The present invention allows a display device 
to prioritize the messages received from multiple network devices or multiple messages 
from a single network device, allows the display device to communicate with other 
network devices over an (IP) based network, and further enables the display device to 
accept detailed display characteristics for a message as part of the received message. 

In accordance with one aspect of the present invention, a method is practiced 
whereby a display device executes a priority messaging protocol which allows the 
display device to efficiently display messages received from multiple network devices. 
A display device executing the protocol of the present invention first requires a network 
device to register with the display device. The display device, which runs the server side 
of the protocol, responds to a registration request from a network device by assigning to 
the network device a Device ID and sending a registration response message back to the 
network device. As part of the registration process, the display device creates a priority 
message queue in the display device's onboard memory for each registering network 
device. Subsequent messages received from the network device are placed in the 
message queue allocated to that network device. Each network device queue is assigned 
a different priority level according to the importance of the network device as 
determined by the user of the display device. Additionally, each message received by 
the display device has a message priority level encoded into the message. The message 
priority level is set by the network device. The messaging protocol executed by the 
display device includes an algorithm which constantly searches for the highest priority 
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message queue containing a message, and then selects the message from within that 
queue which has the highest message priority level for display. The protocol further 
enables the dequeuing ( removal ) of a message from a particular device queue, the 
ability for the display device to provide a network device with a list of all of the 
Message Identification numbers in its assigned queue, and provides for the unregistering 
of the network device when the device is done accessing the display device. 

In an alternative embodiment of the present invention, the network environment 
used by the present invention is located within a motor vehicle. The display device 
receives messages from electronic devices connected to the motor vehicle network, such 
as a CD player, stereo, global positioning satellite receiver, etc. The protocol functions 
exactly the same for a motor vehicle network as it does for networks which are not 
located in a motor vehicle. Those skilled in the art will recognize that the electronic 
devices listed above as part of the motor vehicle network are listed for illustration 
purposes and are not a definitive list of the electronic devices that may be attached to the 
motor vehicle network. 

Brief Description of the Drawings 

Figure 1 is a block diagram illustrating components employed in an illustrative 
embodiment of the present invention; 

Figure 2 is a block diagram of an example configuration for the illustrative 
embodiment of the present invention in a networked environment; 

Figure 3 is a block diagram of the message header packet utilized in the 
illustrative embodiment of the present invention; 

Figure 4A is a flow chart depicting steps performed by the illustrative 
embodiment of the present invention during a device registration request message; 

Figure 4B is a block diagram that shows the format utilized in the body of the 
message packet during a network device registration request and display device response 
to a registration request; 

Figure 5 A is a flow chart depicting the steps followed by the illustrative 
embodiment of the present invention during a Queue Message request; 
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Figure 5B is a block diagram that shows the format utilized in the body of the 
message packet during a Queue Message request and display device response to a Queue 
Message request; 

Figure 5C is a flow chart of the decision sequence of the scheduling algorithm 
employed in the illustrative embodiment; 

Figure 6A is a flow chart depicting steps followed by the illustrative embodiment 
of the present invention during a device's Dequeue Message request; 

Figure 6B is a block diagram that shows the format utilized in the body of the 
message packet during a Dequeue Message request and display device response to a 



™f 10 Dequeue Message request; 



Figure 7 A is a flow chart depicting the steps followed by the illustrative 
embodiment of the present invention during a List Message request message; 

Figure 7B is a block diagram that shows the format utilized in the body of the 
message packet during a List Message request and display device response to a List 
1 5 Message request; 

Figure 8A is a flow chart depicting the steps followed by the illustrative 
embodiment of the present invention during a Status request; 

Figure 8B is a block diagram that shows the format utilized in the body of the 
message packet during a Status request and display device response to a status request 
20 message; 

Figure 9A is a flow chart depicting the steps followed by the illustrative 
embodiment of the present invention during a Unregister request; and 

Figure 9B is a block diagram that shows the format utilized in the body of the 
message packet during a Unregister request and display device response to an Unregister 
25 request. 

Detailed Description Of The Invention 

The illustrative embodiment of the present invention enables a display device to 
receive display requests from multiple network devices communicating with the display 
30 device over an Internet Protocol ( IP ) based network. The priority messaging protocol 
executed by the display device enables a display device to prioritize and display 
incoming messages from different network devices and to prioritize and display multiple 
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incoming messages from a single device. The protocol executed by the display device 
further enables the display device to receive display characteristics encoded as part of a 
message from a network device. The illustrative embodiment of the present invention 
allows a display device executing the priority message protocol to process and display 
5 multiple message requests without the need to prematurely overwrite the message 
currently being displayed or to segment the display surface of the display device into 
smaller pieces. 



Figure 1 depicts a display device configured in accordance with the illustrative 



10 embodiment of the present invention. The display device 2 contains a display surface 4, 
S4 and priority message queues 6, 8, 10 and 12. In the embodiment depicted in Figure 1, 



the display device 2 has created the four priority message queues 6, 8, 10, and 12, to 
hold incoming messages for four respective registered network devices. Messages 
received from the registered network devices are placed in the priority message queue 
1 5 allocated to the respective devices. 

Figure 2 depicts an example of an environment through which the display 
device 2 is accessed. The environment includes a network 14 to which a display 
device 2, a first network device 15, a second network device 16, a third network 
20 device 1 7, and a fourth network device 1 8 are interfaced. The four network 
devices 15-18 each have their own priority message queue 6, 8, 10, and 12. 



The network messaging protocol follows a basic request-response model with the 
display device 2 executing the server side of the protocol and the network devices 

25 executing the client side of the protocol. A network device makes a request by sending a 
message to the display device 2 over the network 14, and the display device 2 responds 
with a response message that is directed back to the network device. Figure 3 depicts a 
packet header 21 utilized by the protocol. The packet header 21 precedes the body of 
each message sent in the protocol. The packet header 21 includes a Version field 22 

30 containing a software release version number for the priority messaging protocol. 

Requests may specify an opcode for a function that the client wishes to perform. To that 
end, the packet header 21 also contains an opcode field 24 containing an indication of an 
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opcode. Each of the responses for the different types of requests has a unique operations 
code ( "opcode" ) that appears in the packet header prior to the body of the response 
message. Correspondingly for each of the requests, the network device places a unique 
opcode in the request packet header. The packet header 21 further contains a Length 
5 field 26 indicating the total length of the remaining packet, and an Application ID field 
( Device ID ) 28 which is unique to each device on the network and is assigned by the 
display device 2 when the device registers with the display device ( See below ). 

In the network messaging protocol, the display device provides responses to 
10 request messages such as Queue Message requests, Dequeue Message requests, List 
%4 Messages requests, Status Requests, and Unregister requests. These requests will be 



described in more detail below. 



Prior to displaying any messages from a network device, the display device 2 
=\ 1 5 must first register the network device. The display device 2 waits to receive a message 

M 1 containing a packet header 21 with an opcode indicating that the packet following the 

C3 

header is part of a Registration request. Because the network device sending the request 
has not registered, the Application ID field 28 in the packet header 21 has been set to 
zero. The registration process is depicted in Figure 4A. A network device 30 sends a 
20 Registration request 32 to the display device 2. The registration request includes both a 
facility code 40 containing the network address of the network device and the device 
name 44 for the network device which are used to identify and locate the network 
device. Upon receiving the Registration request, the display device 2 assigns an 
Application/Device ID 28 to the network device making the request. The display 
25 device 2 sends a Registration Response message 36 containing an Acknowledgement 48 
back to the network device 30. All further communications from the network device 30 
to the display device 2 contains the Application/Device ID 28 within the packet header. 

The frame format for the Registration request is depicted in Figure 4B. The body 
30 of the Registration request 38 includes a Facility Code field 40, and a Length field 42, 
which indicates the length of the Name field 44. The Name field 44 holds a name of the 
network device that is making the registration request. The display device 2 sends a 
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response message 36 ( Figure 4A ) back to the network device 30. The registration 
request response message 36 contains the just assigned Application/Device ID 28 in the 
Application/Device ID field of the packet header 21 . The body of the registration 
request response message 46 contains the Acknowledgment field 48, which contains the 
5 number zero if the device was successfully registered and a non-zero number 

corresponding to a protocol defined error type in the event there was an error in the 
registration process. 



Once a network device has successfully registered with the display device 2, the 

P 10 display device accepts messages intended for display from the network device. 

43 

sj Messages are sent to the display device using a Queue Message request. The sequence 



of events by which the display device receives a Queue Message request is depicted in 
O Figure 5 A. A network device 30 sends a Queue Message request 52 to a display 

iii device 2. The Queue Message request 52 includes a priority level for the message 62, a 

^ 15 type flag 64, and additional information indicating how the message is to be displayed 

M. including a feature flag 66 and delay parameter 68, along with the text 68, 70 and image 

J z 

^ information 72, 74 parts of the message. The display device 2 places the incoming 

r ■ 

M message in the priority message queue allocated to the sending network device. The 

message is assigned a unique Message ID number 80 to distinguish it from the other 
20 messages waiting in the queue. The display device 2 responds to a Queue Message 

request with a Queue Message response 56. The Queue Message response 56 includes 
the Message ID 80 assigned to the message at the time it was placed in the priority 
message queue of the network device, and an Acknowledgement 79. The display 
device 2 uses Message ID's to track messages stored in the priority message queues. 

25 

The details of the Queue Message request frame format are depicted in 
Figure 5B. The body of the Queue Message request 58 includes a Priority field 60, a 
Type Flag field 62 which indicates whether the message is a text message, an image 
message or both a text and image message, and a Feature Flag field 64 which indicates 
30 whether the display surface 4 should first be cleared, whether the message should scroll 
either horizontally or vertically, and whether the message should be persistent, that is, 
stay in the queue after display. The message body 58 further includes a Delay field 66 
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indicating how long the message should be displayed and a Text Length field 68 
indicating the number of bytes in the text string being sent. A Text field 70 containing 
the text bytes, an optional Image Length field 72 indicating the number of bytes in an 
optional optional Image field 74 containing the image bytes in the message. The body 
of the Queue Message response 78 includes a Message ID field 80, the value of which is 
assigned by the display device 2 prior to the placing of the message in the priority 
message queue of the network device. 

In an alternate embodiment, the extensible markup language ( XML ) 
may be used in the present invention. If XML is used for the priority messaging 
protocol, the exact structure of the message will be defined within an XML string. 

The display device 2 makes use of the information contained in the fields of a 
Queue Message request after determining which message is to be displayed. The 
determination of which message to display is reached by use of a scheduling algorithm. 
The display device's scheduling algorithm is implemented by a code which continuously 
checks for new messages. The sequence of events taking place in the algorithm is 
depicted in Figure 5C. The display device will remain in its default display state 77 until 
such time as a network device registers with the display device ( step 79 ). During the 
registration process, the creation of a priority message queue for a network device 
includes the step of assigning a priority level to that network devices queue. The 
scheduling algorithm looks for the network device with the highest priority level 
assigned to its queue ( step 80 ). In the event that the priority message queue having the 
highest priority level also contains messages waiting to be displayed ( step 81), the 
scheduling algorithm searches within that queue for the message to be displayed 
( step 82 ). In the event that the display device 2 determines that the priority message 
queue assigned the highest priority level does not contain any messages waiting to be 
displayed ( step 83 ), the algorithm searches for the next highest priority level ( step 80 ). 
The algorithm continues searching until a message queue with messages waiting to be 
displayed is found ( step 82 ) or there are no of queues left to be searched ( step 83 ). 
Once the scheduling algorithm has located a message queue with messages waiting to 
the displayed, the display device 2 retrieves the message from within that queue that 
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contains the highest priority level ( step 82 ). The message priority level is set by the 
network device at the time it sends a request to enqueue the message. The message may 
contain display characteristic information, such as a request to clear the screen, 
vertically scroll the message, horizontal scroll the message, or have the message be 
persistent. In the absence of such requested display description information, the display 
device will display the message according to previously set default parameters. When 
the message has been displayed for the requisite amount of time, the scheduling 
algorithm seeks out another message to be displayed. The algorithm runs continually as 
long as at least one network device is registered with the display device. 

The illustrative embodiment of the present invention also includes a Dequeue 
Message request. The Dequeue Message request removes a previously sent message 
from the priority message queue of the requesting network device. The sequence of 
steps followed by a display device 2 removing a message from a priority message queue 
in the illustrated embodiment of the present invention is depicted in Figure 6A. A 
network device 30 sends a Dequeue Message request 84, which includes both a Device 
ID 28 identifying the network device, and a Message ID 92 identifying the message the 
network device wishes to remove from its queue, to the display device 2. The display 
device 2, upon receiving the Dequeue Message request 84 , attempts to dequeue the 
message and sends a Dequeue Message response 88 which includes either an 
Acknowledgment 96 or an error message along with a return Message ID 98 identifying 
the message that was removed from the queue in the event the operation was successful. 

Figure 6B depicts the body of the Dequeue Message request 90. The Dequeue 
25 Message request 90 includes a Message ID field 92 identifying the particular message 
which the network device wishes to remove from its queue. The body of the Dequeue 
Message response 94 includes an Acknowledgment field 96 and a Message ID field 98 
indicating the message that was removed from the queue. In the event the message was 
successfully removed, the Acknowledgment field contains the number 0 and the 
30 Message ID contains the Message ID of the removed message. Conversely, if an error 
removing the message was encountered, the Acknowledgment field contains a non-zero 
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number equating to a defined error message and the Message ID field is set to zero 
indicating no message was removed. 

The illustrative embodiment of the present invention also enables a network 
device to request a list of all the Message ID's in the priority message queue assigned to 
that network device. The sequence of events illustrating this List Message request is 
depicted in Figure 7A. A network device 30 sends a List Message request 102 to a 
display device 2. The display device 2 uses the Application/Device ID 28 contained in 
the packet header 21 to check the priority message queue allocated to the network 
device 30 and retrieves a list of the Message ID's 1 16 in that priority message queue. 
The display device 2 sends a List Message response 106 back to the network device 30. 
The List Message response 106 includes an Acknowledgment/Error indicator 112 and a 
length parameter 114 indicating the length of the included list of all of the Message 
ID's 1 16 in the network device's priority message queue. 

Figure 7B depicts the frame format used in the body of the List Message request 
and the body of the corresponding List Message response. The actual body of the List 
Message request is empty as the header contains both the opcode and the Device ID 28 
( i.e. all the information required for the request ). The body of the response to the List 
Message request 110 includes an Acknowledgment field, a Length field 114 indicating 
the length of the rest of the response, and Message ID fields 116, 120, 122 
corresponding to fields for Message ID's one to N. 

The illustrative embodiment of the present invention provides a network 
device 30 with the capability to request the status of a particular message in its priority 
message queue. Figure 8 A depicts the sequence of events by which a network device 30 
requests the status of a particular message in its priority message queue. A network 
device 30 sends a Status request 126 which includes the Message ID 134 for which a 
status update is requested. The display device 2 uses the Device ID 28 and the Message 
ID 134 to retrieve the message from the priority message queue allocated to the 
requesting network device and examines the message's details such as priority level and 
display characteristics. The display device 2 then sends a Status response 130 which 
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includes an Acknowledgment/Error indicator 138, the message's priority level 140, type 
and feature flags 142,144 and a delay parameter 146, all of which mirrors the 
information in the message stored in the priority message queue. 

Figure 8B depicts the message body of the Status request 132 which contains a 
Message ID field 1 34, as the message header Opcode indicates the message was a status 
request. The message body of the Status request response 136 includes an 
Acknowledgment field 138, a Priority field 140 indicating the messages priority, a Type 
Flag field 142 indicating the type of message, text, image, or both text and image, a 
Feature Flag field 144 indicating the display features associated with the message, and a 
Delay field 146 indicating the length and time the message is to be displayed. This 
information provides a snapshot of how the display device 2 recorded the message in the 
priority queue. 

The illustrative embodiment of the present invention also includes an Unregister 
request which is sent by a network device when it has completed accessing the display 
device. Figure 9A depicts the steps of the Unregister request. A network device 30 
sends an Unregister request 150 to the display device 2. The display device 2 
deallocates the priority message queue assigned to the requesting network device 30 and 
sends an Unregister response 154 containing an Acknowledgment/Error indication 160 
back to the network device 30. 

Figure 9B depicts the message body of the Unregister request 156 which is 
empty, as the message header opcode 24 indicates the message is an Unregister 
Request 1 56, and the particular Device ID 28 is also contained in the packet header 21 . 
The body of the Unregister response message 158 consists solely of an 
Acknowledgment/Error field 160. 

It will thus be seen that the invention efficiently attains the objects made 
apparent from the preceding description. Since certain changes may be made without 
departing from the scope of the present invention, it is intended that all matter contained 
in the above description or shown in the accompanying drawings be interpreted as 
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illustrative and not in a literal sense. Practitioners of the art will realize that the separate 
requests and responses illustrated herein may have fields added to the request or 
response, and/or may have fields deleted from the request or response, and additional 
types of requests and responses may be added from one protocol version to the next 
without departing from the scope of the present invention. 
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